feat(admin): add operations console for mirrors, workers, and NIP-05 - #895

Review: approve-level

Verified independently on the PR head: the 5 new admin-ops unit tests and the 8 relay-monitor worker tests pass, tsc reports no errors in any PR file, and biome lint (what CI runs) is clean on all new/changed source. The security-relevant claims check out: all five routes carry the identical adminRateLimitMiddleware + adminAuthMiddleware chain as their neighbors, the storage-counts query parser bounds kinds (max 20, 0–65535) and the time window (90 days) with a 5s statement timeout mapped to 504, the NIP-05 list clamps limit/offset and validates minFailures with everything parameterized through knex, the reverify endpoint schema-validates the pubkey and 404s/409s/502s correctly, and the dashboard escapes every interpolated value (escapeHtml/escapeAttr on the user-controlled NIP-05 identifiers included) — the #110 lesson visibly applied. Heartbeat publishing is properly failure-isolated so a Redis outage can't break the workers, intervals are cleared on exit, and the changeset is included this time.

One finding that should be fixed before merge:

The relay-monitor keepalive wipes the per-run heartbeat. publishWorker does a full setKey overwrite, and the 45s keepalive publishes a bare {type: 'relay-monitor', updatedAt} — no lastError, no run timestamps. So a failed probe run's lastError vanishes from the Operations dashboard within 45 seconds even though nothing recovered; the panel reads "Live" with no error until the next probe run, which may be far later. The static-mirroring worker doesn't have this problem (its keepalive republishes full state). The keepalive should re-publish the last known partial (kept in a member field) rather than a bare liveness ping — otherwise the worker-ops panel misleads exactly when it matters.

Further notes, non-blocking:

• Thin tests for the size. 1725 additions, 5 new unit tests. The pure functions (sanitizeAdminOpsError, isAdminOpsHeartbeatStale, mergeMirrorRows/mergeWorkerRows) and the store's TTL/index logic are all easily unit-testable — and the keepalive finding above is exactly the class of bug a store-level test would have caught.
• The heartbeat index set never shrinks. Dead mirror:<index> / worker:<type>:<index> members are skipped on read (missing key → continue), but they accumulate in admin:ops:heartbeat:index forever — a slow Redis memory leak across config changes over a relay's lifetime.
• getAdminOpsStore is a singleton that silently ignores the cache argument on later calls. Fine with one cache per process, but an assertion would be cheaper than a future mystery.
• Template checklist unfilled again — though the changeset made it in this time, which is the part that matters.

Review update: requesting changes

Revising my verdict on this one — approve was the wrong call, and the coverage question is what settled it.

The keepalive clobber isn't a polish nit: it silently wipes a failed probe run's error from the Operations dashboard within 45 seconds, which is the exact opposite of what this feature is for. And the new tests cover ~15% of the new backend code (zero on the store, the controllers, the sanitizer, the config merge) — so nothing in the PR's own suite guards the fix or would catch the next bug of the same shape. A real functional bug in the feature's core purpose, plus tests that can't see it, is request-changes.

What flips it back: have the relay-monitor keepalive re-publish the last known heartbeat state instead of a bare liveness ping, and add store-level tests covering publish/list/stale behavior plus the keepalive interaction. The pure functions (sanitizeAdminOpsError, mergeMirrorRows/mergeWorkerRows, isAdminOpsHeartbeatStale) are cheap to cover and would have caught this class of bug.